An audit of the enabled=false test methods across the sibling modules
found four disabled without any stated reason (the remaining ones all
document why they are off). All four pass once enabled:

- LDIFEntryWriterTestCase.testSetAddUserFriendlyComments and
  LDIFChangeRecordWriterTestCase.testSetAddUserFriendlyComments pass
  as-is;
- GrizzlyLDAPListenerTestCase.testLDAPListenerLoadBalanceDuringHandleAccept
  passes as-is;
- GrizzlyLDAPListenerTestCase.testLDAPListenerProxyDuringHandleAccept
  contained a copy-paste error: the client connected to the online
  server directly instead of to the proxy listener, so the proxy
  handleAccept was never invoked and the test timed out waiting for
  the proxied connection. Connect to the proxy listener instead.

- Rename TemplateTagTestcase to TemplateTagTestCase: the lowercase "c"
  never matched the *TestCase include pattern, so its 21 tests never
  ran (all pass).
- PropertyDefinitionUsageBuilder.visitString threw a NullPointerException
  for string properties which define a pattern but no pattern synopsis,
  breaking error message generation for pattern validation failures -
  the "I18N problem" that kept two StringPropertyDefinitionTest methods
  disabled. Append the synopsis only when present and enable the tests.
- ValidateConfigDefinitionsTest.validateConfigObjectDefinitions,
  DefaultTCPNIOTransportTestCase.testGetInstance and
  ConnectionFactoryTestCase.testSchemaUsage carry stale disable reasons
  (a TODO about unavailable object classes, an unclean-environment
  FIXME and OPENDJ-159): all pass now, twice in a row, together with
  their neighbouring classes.

Still disabled with valid reasons: the entry generator debug printer,
the GSSAPI bind test (needs a KDC), the rest2ldap case-insensitive
field selection (CREST-86, confirmed still failing) and the
Windows-only FileManagerTest case.

…lidator

The test was re-enabled in OpenIdentityPlatform#707 but only stayed green because its
assertion was inverted (errors.length() != 0), so it passed precisely
when a definition had problems. Its schema-consistency checks also
cannot run in opendj-config, where the ds-cfg-* LDAP schema is not on
the test class path (object classes/attributes resolve as placeholders)
- the reason behind the original "TODO: can't retrieve object class objects".

Fix the assertion to == 0, drop the schema-dependent checks, and keep the
naming-convention checks verifiable from the definitions and their LDAP
profiles alone. Fixing the assertion surfaced three real issues, now fixed:
- CLASS_OBJECT_CLASS_EXCEPTIONS referenced the obsolete
  org.forgerock.opendj.config.std.meta package; updated to
  org.forgerock.opendj.server.config.meta (root/global).
- http-endpoint's authorization-mechanism intentionally maps to
  ds-cfg-http-authorization-mechanism; added LDAP_ATTRIBUTE_NAME_EXCEPTIONS.